Nym 安全审查

对Nym核心部分的安全审计

1 分钟已读

简介

2021年7月，Nym接受了著名安全专家[Jean-Philippe Aumasson]（https://www.aumasson.jp/）的安全审计。目标是查明Nym codebase可能存在的脆弱性和缺陷，重点是加密、代码安全和协议安全。审查的目的是确保该系统的完整性和健全性，包括其结构和实施的关键方面。您可以看到完整的审计报告 here。

审计摘要

审计工作于2021年夏季进行。审计范围涵盖Nym项目的多个存放处，包括：

Nym的主仓库：nymtech/nym，它实现了混合节点、网关和验证器服务。
Sphinx Mixnet Packet 格式：nymtech/sphinx，用于混合节点。
Coconut 临界值签名协议：nymtech/coconut，用于颁发证书。

审计工作包括审查开发处最新版本的代码，由于项目的快速进化而定期更新该代码。 Nym小组让JP Aumasson能够完全查阅代码表、详细的项目规格、研究论文和佐证文件。

审计的主要重点领域

审计侧重于三个主要领域：代码安全、加密法和协议设计。审计员们彻底检查了Nyms的代码库，以查明薄弱环节，寻找诸如不安全编码模式等常见问题和错误误解。对内存安全和避免整数过多等陷阱给予了特别关注。

加密审查涵盖范围广泛的Nym使用的核心原始数据，如AES-128-CTR、BLAKE2b、Chap、Ed.25519和其他。其目的是确保这些算法得到适当实施，并核实其抵制侧道攻击、误用参数和随机生成的缺陷。

除了审查每个组成部分外，审计还调查了界定Nym核心功能的协议。这涉及对Sphinx数据包格式和[Coconut阈值盲签名协议](https://nym.com/blog/ nym-credentials-a-decentralized-private-alternative-to-the-faceopticon)进行分析，以识别可能危及隐私或安全的任何漏洞。审查的重点是潜在的信息泄露威胁到用户匿名性的信息，以及诸如MAC核查绕道等薄弱环节，诸如BLS12-381测算和零知识证明等密码操作中的小群攻击和缺陷。

二. 调查结果概述

在审计期间发现了九个安全方面的弱点。没有一个被评为临界值，两个被评为很高，一个被评为中等，六个被评为较低。此外，还提出了17项意见，为进一步加强Nym网络提出了建议。下文概述了为解决所有已查明的安全脆弱性而采取的补救措施。

S-SPHX-01：缺少密钥验证(Low)

在 nymtech/sphinx 中发现的私钥和公用钥匙验证不足的问题已经由 [migrating](https://github.com/nymtech/sphinx/pull/94解决到 x25519 库，它本身就通过其设计来强制执行关键的有效性。 x25519实现确保私钥被正确地夹住，表示它们会被自动限制在有效的比例尺子集中，消除使用无效私钥的风险。此外，虽然x25519没有明确验证公钥，但其Montgomery阶梯的实现固有地防止某些无效的曲线点被使用。这就减少了在无限或其他错误的公共钥匙中碰到地点的风险。此外，关键的交换程序确保能够发现并在必要时拒绝一个完全为零的共享秘密。通过使用 x25519 ，我们大大改进了密钥验证，减少了系统内使用无效或格式不当的密钥的风险。这有效地解决了审计中对关键验证提出的关切。

S-COCO-01：按比例分布偏差(低)

生成BLS12-381字段缩放的散列过程先前涉及绘制散列函数输出直接到缩写字段元素。然而，这种做法由于模块化削减作业而造成了偏差。当散列输出不完全符合字段的主模块时，它可以导致不统一的分布。为解决此问题，我们用bls12_381 crate中的[hash_to_field](https://github.com/jstuczyn/bls12_381/blob/22cd0a16b674af1629110a2dc8b6cf6c73ea4cd9/src/hash_to_curve/mod. rs#L44)函数，该函数来自bls12_381 crate。该函数遵循标准化哈希到字段规范，确保哈希输出与字段元素之间实现统一且无偏见的映射。此外，取代Coconut协议的锌-Nym协议也依靠这一功能进行散列操作，确保加密计算的一致性和正确性。

S-COCO-02: keygen-cli 密钥文件权限(低)

审计员们注意到，keygen-cli 密钥文件拥有默认权限，但是他们应该有更多的限制权限来提高安全性。这个问题不需要任何修改，因为关键词刚刚在我们科库诺特实施阶段使用。它不再是Nym主仓库的一部分，也没有在使用中。由于该工具已经过时，不需要对其文件权限采取进一步行动。

S-CRYP-01: 第四期潜在流密码重新使用(高)

这个问题涉及一个使用初始化矢量(IV)加密数据的函数。如果没有提供四点，该函数默认使用零四，这可能导致四次重新使用。这个问题已经通过在登记阶段引入AES-GCM-SIV协议得到解决。为了防止降级攻击, 我们有 [removed](https://github.com/nymtech/nym/pull/5531选项, 使用旧的 AES-128-CTR 键进行客户端和网关之间的通信。只要客户端和网关都被更新，它们总是会生成一个随机的、非零的IV。

S-PROT-01: 可能的双重使用凭据(高)

审计员注意到，经过审查的科库努特版本缺乏双重支出检测机制。它可能允许多个网关错误地验证凭据同时未使用。然而，科库诺特带宽合同后来得到更新，以便通过储存链上的状态来跟踪凭据使用情况，解决这一问题。此外，椰子已经被zk-nyms protocol取代，其中包括内置的双支出检测功能。

S-NYM-01：具有已知脆弱性的依赖关系(中等)

审计员发现Nym项目的几个部分依赖于已知的安全薄弱环节的旧版本的依赖关系。例如，Sphinx 存储库使用了不安全的通用数组cray版本，Nym的核心存储库依赖于过时的tokio`，而且Nym客户有几个带有已知安全问题的箱子，其中一些看来在Nym环境中是可以利用的。根据审计员的建议，我们定期更新附属机构。我们现在通过“Dependabot”来积极管理我们的依赖，它持续监视和自动检测到我们仓库中过时或易受伤害的软件包。查看我们仓库中Dependabot修复程序的持续应用。

S-NYM-02：解密故障未处理 (Low)

代码中指明的问题发生在nym/common/nymsphinx/recogments/identifier.rs中的recover_identifier函数中，解密失败，如无效参数，未得到适当处理。这可能导致恐慌或其他不安全的国家。 nym/common/nymsphinx/src/receiver.rs中的recover_plaintex函数中存在类似的问题。无法管理解密可能导致系统进入不稳定或不安全状态。在仔细审查了这些职能之后，我们得出的结论是，在recovery_identifier中提供的第一个例子是没有问题的。提供不正确的参数是不可能的，因为一切都被AckEncryptionAlgorithm (link参数化了。表示任何无效的值都会在编译时被抓到。他们提到的第二个案例recover_plaintxt，不再存在。然而，取代它的代码，recover_plaintxt_from_regular_packet，如果我们要修改一些参数到不寻常的值的话，则有一个理论上可能的失败案例。我们通过添加适当的错误处理来解决这个问题，确保系统即使在边界情况下也能保持稳定。

S-NYM-03：片段ID生成时出现恐慌(低)

用于生成新片段 ID 的代码随机选择一个 i32 值并获取其绝对值。然而，如果随机选择的值是“i32::MIN”，这种做法可能会引起恐慌。因为它的绝对值不能在i32的范围内表示. 这导致由于两种补充编码的局限性，“试图以溢出方式取消”错误。我们同意为这个问题设置的严重程度评级过低。因为遇到这种情况的可能性大约是40亿分之一。然而，我们已经解决了落实审计员建议的修复以防止潜在的恐慌和意外崩溃的问题，尤其是数以百万计的用户产生了数以千计的片段ID。

S-NYM-04: 毫微秒非零化(低)

查明的问题突出表明，用于连接神经服务的BIP39 mnemon在使用后并没有变为零。导致内存内存内存中多次复制。这增加了暴露风险，因为与原密码密钥相比，mnemonic在内存中更容易辨认。为了解决这个问题，我们实施了几项缓解。在Rust 组件中，我们已经集成了 zeroize crate ，以确保含有mannemon的任何内存一旦超出范围，都会被安全擦除。因为JavaScript是一种垃圾收集的语言，不能直接控制内存处理。我们采取了不同的方法来减少JavaScript运行时的曝光。具体而言，我们已经修改了系统，以便一旦mnemon传递到Rust层，JavaScript运行时间就会终止。这将确保运行时关闭时清除JavaScript内存中的所有模型。助记符将尽早传送到Rust, 减少它在 JavaScript 中的暴露。在 Rust, zeroize 内会确保在不再需要时，所有助记符的实例都会被安全擦除。通过这些更改，我们已经大大减少了mnemonic在内存中的存在。减少暴露风险，确保敏感数据得到安全管理和删除。

最后单词

我们要感谢JP Aumasson在整个审计过程中所表现出的专门知识和奉献精神。我们还赞赏在审计的规划和执行阶段所表现出的合作和专业精神。我们对安全的持续承诺仍然是最高优先事项。我们期待着继续与安全专家建立伙伴关系，以维护我们生态系统的最高标准。